В данной статье посмотрим, в каком месте CandleConnector подписывается на бумаги в AServer. Какие методы ServerRealization при этом вызываются и откуда.
Регион, который нам нужен:
Проверка способности коннектора выставлять и отзывать лимитные ордера без его исполнения. Минимум 20 циклов для Buy и Sell.
Сегодня поговорим об этапах разработки непосредственно исходного кода коннектора. Большими мазками. Как это делаю я, со стороны программирования. Вопросы подготовки и сдачи коннектора пока здесь не рассмотрены. Об этом у нас в других статьях.
Итак, Вы уже начинающий программист:
Как это не смешно, но первое, что надо сделать, это определиться с документацией и убедиться, что все нужные документы есть под рукой.
Обычно, если дело касается криптобирж, бывает по две или три одновременно поддерживаемых API для одной площадки. Нужно выбирать крайнее и новое.
Тест, валидирующий ордера и события о торговле. Тип ордера — Market. Сторона Buy и Sell отдельно.
Каждый экземпляр AServer может сохранять трейды и свечи, которые поступают из источников и собираются на месте. Каждому программисту, который будет делать коннекторы было бы не плохо знать где это происходит. Об этом и поговорим.
Объекты, сохраняющие свечи и трейды в AServer.
Тест, валидирующий ордера и события о торговле. Тип ордера — Лимит. Сторона Buy и Sell отдельно.
Тест, проверяющий возвращение статуса ордера FAIL в тот момент, когда высылаются ошибочные цены и объёмы на открытие позиции.
Сегодня будем разбираться с тем, кто и как запрашивает у AServer данные по свечкам и трейдам. Делают это две подсистемы: OsData и CandleManager. Обсудим обе.
Регион, в котором предоставляются методы для получения данных из коннектора.
Обзор теста, проверяющего наличие заявленных таймфреймов в разрешениях свечек в боевом подключении.
Ордера в OsEngine высылаются в IserverRealization не напрямую, а через отдельную очередь. Посмотрим на неё одним глазком.